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ABSTRACT 

Advanced  simulation  and  modelling  technology  has  provided  the  military  establishment  with  a  new  and 
unprecedented  opportunity  to  experiment  with  concepts  and  doctrine  in  a  way  that  today ’s  constraints  on 
cost  and  resources  have  made  extremely  difficult  to  realise  by  any  other  methods.  Simulation  and 
modelling  technology  enables  a  greater  range  of  options  to  be  explored,  the  flexible  arrangement  of  real 
and  the  simulated  participants  and  the  rapid  development  and  demonstration  of  new  concepts,  all  leading 
to  a  powerful  capability  for  shaping  the  future  of  military  operations.  This  technology  can  be  used  to 
underpin  experimentation  which  explores  and  defines  concepts  and  processes  for  future  doctrine  such  as 
the  United  Kingdom  (UK)'s  Network  Enabled  Capability  (NEC)  and  Effects  Based  Operations  (EBO). 

Without  some  framework  for  managing  the  resulting  information  and  to  provide  a  wider  scope  for 
interpretation  of  results,  the  full  benefit  of  this  type  of  experimentation  can  remain  unfulfilled.  Based  on 
work  conducted  on  behalf  of  the  UK  Ministry  of  Defence  (MOD)  and  the  UK  NITEworks1  programme,  this 
paper  shows  the  benefits  which  have  been  gained  from  an  architecture  framework  based  model  repository 
to  provide  a  conceptual  architecture  for  managing  and  exploiting  experimental  architectures  and 
observations. 


1.0  INTRODUCTION 

Today’s  current  climate  of  increased  commitments  of  UK  forces,  the  prominence  of  homeland  security, 
changing  threats  coupled  with  rapidly  evolving  technology,  increased  complexity  of  integration  and  tighter 
controlled  defence  expenditure  has  lead  to  experimentation  as  the  means  of,  providing  an  effective  way  to 
support  the  definition,  development  and  delivery  of  Networked  Enabled  Capability  (NEC)  [1]  and  Effects 
Based  Operations  (EBO).  Not  only  must  this  experimentation  deal  with  the  development  of  new 
capability,  but  importantly  it  must  concern  itself  with  existing  capability  as  acknowledged  by  the  UK 
Defence  Industry  Strategy  [2]; 

“..  unless  systems  engineering  capability  and  vital  long-term  knowledge  is  maintained,  it  is  little  use 
investing  in  cutting-edge  science.  New  technologies  will  have  less  benefit  without  knowledge  of  how  they 
might  be  exploited  and  inserted  into  existing  equipment.  ”2 


1  NITEworks  is  a  Registered  Trademark® 

2  Defence  Industry  Strategy,  Section  B.l  System  Engineering,  para  B.1.4 

King,  P.;  Evans,  D.  (2006)  The  Use  of  a  Conceptual  Battlespace  Architecture  to  Manage  and  Exploit  Concepts  and  Doctrine 
Experimentation.  In  Transforming  Training  and  Experimentation  through  Modelling  and  Simulation  (pp.  6-1  -  6-12).  Meeting 
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to  Manage  and  Exploit  Concepts  and  Doctrine  Experimentation 


Within  the  UK,  a  joint  MOD-industry  experimentation  programme  known  as  NITEworks  is  at  the 
forefront  of  this  effort  to  deliver  an  experimentation  environment  to  enable  the  UK  MOD  to  assess  the 
benefits  of  NEC  and  the  options  for  its  effective  and  timely  delivery.  NITEworks  responds  to  specific 
issues  posed  by  the  UK  MOD  and  uses  experimentation  to  propose  solutions  in  terms  of  changes  to: 

•  operational  development,  expressed  as  changes  to  concepts  and  doctrine; 

•  warfighter  development,  in  terms  of  how  current  capability  is  deployed; 

•  capability  development,  whether  through  enhancement  to  existing  equipment  or  development  of 
new  equipment. 

After  the  completion  of  several  experiments3  NITEworks  recognised  that  there  was  potential  overlap 
between  experiments  and  this  could  be  exploited  to  gain  additional  insight  into  the  NEC  issues  that 
NITEworks  addresses.  An  experiment  addresses  a  set  of  specific  issues  raised  by  the  MOD  community. 
The  experiment  is  constructed  to  reflect  a  specific  operational  context  and  system  configuration,  and 
reports  specifically  on  the  issues  it  is  addressing.  In  April  2005  work  was  started  to  develop  and 
demonstrate  a  methodology  and  process  to  enable  this  additional  value  to  be  obtained  from  across  a 
number  of  experiments  and  external  references.  The  aim  was  to  find  an  approach  which  would  enable 
observations  from  different  experiments  to  be  used  to  inform  common  elements  from  the  experiments,  and 
to  promote  the  ability  to  learn  about  the  general  from  the  specific.  This  paper  describes  a  process  and 
methodology  designed  to  achieve  these  aims,  and  the  lessons  that  have  been  learnt  in  developing  a 
conceptual  battlespace  architecture  to  realise  its  value. 

2.0  BACKGROUND 

2.1  Integration  Authority 

Within  the  UK  MOD  acquisition  community,  individual  Integrated  Project  Teams  (IPTs)  are  responsible 
for  delivering  specific  equipment  programmes,  but  in  many  cases  the  military  capability  sought  can  only 
be  realised  through  the  interoperation  of  two  or  more  projects.  This  can  only  be  achieved  through  the 
close  co-ordination  at  the  planning  and  design  stages,  and  for  the  integration  and  testing  of  the  related 
equipment  before  delivery. 

The  Integration  Authority  (IA)  has  been  established  within  the  Defence  Procurement  Agency  (DP A)  to 
facilitate  these  activities  to  ensure  a  coherent  acquisition  of  military  capability.  Part  of  the  IA  activity  is  to 
provide  an  architectural  centre  of  excellence;  to  develop  an  architecture  framework  (i.e.  MODAF4)  and 
develop  an  architectural  representation  of  the  battlespace.  In  support  of  these  objectives  the  IA  has 
commissioned  the  development  (by  VEGA  Group  PLC)  of  the  Integration  Services  Support  Environment 
(ISSE)  as  a  combined  MODAF  compliant,  EA  modelling  and  architecture  repository  solution. 

2.2  NITEworks 

NITEworks  is  an  innovative  partnership  between  the  UK  MOD  and  Industry  to  deliver  experimentation  in 
support  of  NEC.  NITEworks  provides  an  experimental  environment  that  allows  the  UK  MOD  to  asses  the 
benefits  of  NEC  and  the  options  for  its  effective  and  timely  delivery.  The  partnership  arrangement  enables 
the  UK  MOD  and  Industry  to  gain  a  common  understanding  of  the  problems  faced  by  the  warfighter,  and 
to  work  together  to  identify  solutions,  drawing  on  the  expertise  offered  by  Industry.  NITEworks  seeks  to 

[3]; 

3 

NITEworks  refers  to  an  experiment  that  addresses  a  set  of  specific  issues  as  a  ‘theme’.  For  the  purpose  of  this  paper,  the  term 
‘experiment’  has  been  used. 

4  The  MOD  Architecture  Framework  (MODAF)  is  an  Architectural  Framework  which  has  been  designed  to  meet  the  specific 
business  and  operational  needs  of  the  MOD.  (see  www.modaf.com) 
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•  Gain  an  understanding  of  NEC  based  on  the  UK  MOD’s  priority  issues  across  all  the  lines  of 
development; 

•  Demonstrate  the  value  of  experimentations  to  NEC; 

•  Identify  where  innovative  technology  could  be  exploited. 

The  NITEworks  team  is  made  up  of  core  personnel  from  the  UK  MOD  and  industry  who  work  as  a  single, 
integrated  team.  The  team  is  supplemented  by  additional  resources  to  provide  specific  expertise  to  support 
dedicated  experiments. 


3.0  GENERALISING  THE  SPECIFIC 

Looking  at  NITEworks  as  a  whole,  there  are  three  issues  arising  from  the  way  experiments  are  conducted. 
Firstly,  how  can  the  knowledge  (which  is  documented  in  the  form  of  observations  and  recommendations, 
of  which  there  are  plenty)  acquired  during  one  experiment  be  meaningfully  re-used.  Secondly  can  the 
observations  and  recommendations  made  in  the  specific  context  of  one  experiment  be  applied  to  other 
similar  circumstances.  And  lastly,  and  to  some  extent  predicated  by  the  first  two  issues,  can  the  results  of 
previous  issues  be  used  to  address  new  issues. 

Since  NITEworks  experiments  are  conducted  to  address  specific  issues  within  a  specific  operational  and 
system  context,  the  challenge  is  to  establish  a  broader  environment  in  which  the  specific  elements  of  an 
experiment  can  be  either  generalised  or  related  in  a  meaningful  manner  to  more  general  concepts.  If  this  is 
possible  it  should  then  be  feasible  to  apply  the  experimental  findings  to  other  specific  circumstances 
identified  by  the  general,  or  information  which  is  gathered  about  a  number  of  examples  of  the  general  can 
be  used  to  build  evidence  for  wider  recommendations  for  operational,  warfighter  or  equipment 
development. 

For  instance,  suppose  an  experiment  makes  observations  about  the  targeting  process  for  smart  munitions 
within  a  Brigade  HQ.  Then  it  would  be  sensible  to  look  how  these  relate  both  to  HQs  in  general  (that  is  to 
the  targeting  process  in  a  general  “Command  Node”  and  also  to  targeting  process  for  general  munitions). 
This  can  than  be  potentially  used  to  make  recommendations  about  other  specific  “Command  Nodes”,  such 
as  a  Combined  Air  Operations  Centre  (CAOC). 

Of  course  the  notion  of  generalisation,  and  analysis  of  the  features  of  concepts  and  relationships  between 
them,  is  the  stuff  of  the  related  disciplines  of  “class  modelling”  and  “taxonomy”.  Through  the  application 
of  ideas  from  modelling  in  general,  and  taxonomy,  the  notion  of  a  “conceptual  battlespace  architecture” 
grew.  There  are  two  types  of  input  to  the  conceptual  battlespace  architecture  observations  and 
recommendation  from  experiments,  concepts  and  doctrine.  Generalised  entities  (such  as  “Command 
Node”)  and  their  features  (both  properties  and  behaviours)  and  relationships  were  derived  both  from 
observations  and  recommendations,  and  from  concepts  and  doctrine  which  were  also  used  to  index  and 
classify  the  resulting  conceptual  entities. 

To  sum  up  the  problem  in  an  aphorism,  the  premise  on  which  the  use  of  conceptual  architectural 
modelling  is  based  is  that  the  sum  is  greater  than  that  of  individual  parts.  That  is,  within  NITEworks  the 
combination  of  the  results  of  a  number  of  different  experiments,  together  with  information  from  other 
sources,  should  provide  a  greater  understanding  of  NEC  than  that  could  be  obtained  from  a  single 
experiment. 
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The  result  was  a  conceptual  battlespace  architecture  with  the  following  objectives: 

•  Improved  capability  to  deliver  future  experimentation.  Future  experiments  could  identify  and 
reuse  existing  knowledge  to  enable  an  understanding  of  the  problem  domain  to  be  achieved 
quicker  and  hopefully  cheaper  and,  by  drawing  on  the  aggregated  knowledge,  hopefully  better. 

•  The  provision  of  derived  knowledge  from  experimentation.  The  accumulated  and  derived 
knowledge  from  a  number  of  experiments  will  provide  a  better  understanding  on  how  to  realise 
NEC.  The  availability  of  this  derived  knowledge  can  be  used  to  support  ongoing  issues  or  may 
even  replace  the  need  for  future  experimentation  into  the  issue. 

•  An  enhanced  architectural  description  of  the  battlespace.  The  consistent  and  coherent 
incorporation  of  architectural  material  from  a  range  of  activities  will  provide  an  improved 
architectural  description  of  the  battlespace  that  will  support  the  wider  UK  MOD  community  and 
in  particular  the  IA  in  developing  a  battlespace  representation. 

In  order  to  fully  realise  the  desired  benefits  of  the  adopted  architectural  approach  would  require  the  ability 
to  construct  queries  based  on  an  underlying  meta-model  which  facilitate  analysis  of  complex  relationships 
within  the  architecture,  together  with  the  ability  to  manage  an  extensive  repository  of  consistent  models. 
The  realisation  of  this  approach  was  a  conceptual  battlespace  architecture  with  the  key  features  shown  in 
Figure  1. 


Situate  experimentation  in  the 
Battlespace. 

The  ability  for  current  and  planned  experimentation  to  gain  an 
initial  understanding  of  the  problem  domain  to  enable  the 
identification  of  potential  areas  of  overlap  and  reuse  with 
existing  experimentation  and  to  identify  stakeholders. 

Carry  out  semantic  searches  of 
Knowledge. 

To  overcome  the  inevitable  variation  in  terminology  a  semantic 
means  to  identify  potential  areas  of  knowledge  for  reuse. 

Generate  Battlespace 

Templates 

The  means  to  reuse  architectural  understanding  in  the 
generation  of  new  experimental  architectures  through  the  use 
of  templates  and  patterns. 

Generate  Derived  knowledge  to 
support  both  new 
experimentation  and  doctrine. 

To  support  the  collation  of  like  meaning  things  to  enable  an 
analyst  to  derive  and  capture  knowledge  to  support  future 
reuse. 

Figure  1  -  The  ‘key’  features  of  the  conceptual  battlespace  architecture. 


4.0  THE  CONCEPT 

4.1  Conceptual  Battlespace  Architecture 

The  conceptual  battlespace  architecture  is  the  elicitation  of  concepts,  patterns  and  trends  from  the 
Battlespace5  represented  in  experiments,  which  are  then  conceptualised  to  enable  them  to  be  re-applied  in 
different  areas  of  the  Battlespace  without  the  need  to  undertake  experimentation.  In  essence,  the  aim  is  to 
identify  the  fundamental  rules  that  govern  the  Battlespace  and  then  represent  these  as  architectural  patterns 
and  observations  which  can  then  be  reused.  The  approach  is  analogous  to  the  identification  of  patterns  in 
software  engineering  [4],  which  in  turn  have  been  developed  from  the  recognition  of  the  importance  of 
patterns  in  constructing  traditional  (building  and  city)  architecture  expounded  by  Christopher  Alexander 
[6]. 


5  Within  the  context  of  this  work  the  term  ‘Battlespace’  refers  to  the  domains  of  the  experiments,  architectural  representations 
and  doctrine  that  have  been  used  as  source  information. 
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An  overview  of  the  structure  of  the  conceptual  battlespace  architecture  is  shown  in  Figure  2.  From  a  range 
of  source  information6  (that  describes  the  battlespace)  a  number  of  entities  are  derived  and  classified  into 
an  architectural  framework.  These  entities  are  then  abstracted  within  the  framework  to  identify 
commonality  and  to  enable  aggregation  to  occur.  These  ‘conceptual  entities’  represent  the  conceptual 
battlespace  and  are  used  to  support  the  development  of  architectural  patterns.  These  patterns  are 
subsequently  expanded  by  observations,  and  form  the  building  blocks  of  the  whole  conceptual 
architecture. 


Patterns 


Conceptual 

Layer 

Categorised  into 
Architectural  Framework 


Battlespace 

Layer 

Categorised  into 
Architectural  Framework 


Source  Information 
Layer 

Categorised  into 
Architectural  Framework 


Figure  2  -  An  overview  of  the  elements  of  the  conceptual  battlespace  architecture. 


4.2  The  Need  for  an  Architectural  Framework 

Within  each  layer  of  the  architecture  a  means  is  required  to  enable  the  identification  and  collation  of  like 
entities,  and  to  provide  a  structure  to  support  the  construction  and  maintenance  of  the  model.  An 
architectural  framework  is  the  obvious  approach  to  realise  this,  and  the  Zachman  Enterprise  Framework7 
[4]  was  adopted.  The  Zachman  Framework  is  widely  used  in  industry,  and  unlike  other  frameworks,  it 
provides  a  structure,  in  the  form  of  a  matrix,  according  to  which  information  can  be  directly  classified. 
Only  the  top  four  layers  of  the  Zachman  Enterprise  Framework  were  used,  as  only  these  layers  were 
warranted  by  the  scope  of  the  available  source  information.  Additionally,  in  order  to  provide  a  reference 
point  for  stakeholders,  cells  within  the  framework  were  given  a  military  tag.  The  adapted  Zachman 
Framework  is  shown  in  Figure  3. 


6  For  example  experimental  findings,  experimental  architecture,  doctrine,  concepts  etc. 

H 

The  Zachman  Framework  for  Enterprise  Architecture™  is  a  trademark  of  John  A.  Zachman  and  Zachman  International 
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Data 

Function 

Network 

People 

Time 

Motivation 

Scope 

OPERATIONAL 

DRIVERS 

List  of  things  important  to 
the  business 

OPERATIONAL 

CAPABILITY 

List  of  processes  the 
business  performs 

BATTLESPACE/ 

STRUCTURE 

List  of  Locations  in  which 
the  business  operates 

STAKEHOLDERS 

List  of  Organisations 
Important  to  the  Business 

PROGRAM 

List  of  Events  Significant 
to  the  Business 

STRATEGIC  EFFECT 

List  of  Business 
Goals/Strategies 

Business  Model 

OPERATIONAL 

INFORMATION 

OPERATIONAL 

PROCESS 

OPERATING 

ENVIRONMENT 

OPERATIONAL 

ROLE 

PROGRAM 

ACTIVITY 

OPERATION 

Semantic  Model 

Business  Process  Model 

Business  Logistics 
System 

Work  Flow  Model 

Master  Schedule 

Business  Plan 

DATA  MODEL 

SYSTEM 

DOMAINS 

USERS 

Business  Rule  Model 

System  Model 

Logical  Data  Model 

Application  Architecture 

Distributed  System 
Architecture 

Human  Interface 
Architecture 

IMPLEMENTATION 

INFRASTRUCTURE 

Rule  Design 

Technology  Model 

System  Design 

Technology  Architecture 

Key: 


Military  Context 

Zachman  Definition 


Figure  3  -  The  first  four  layers  of  the  Zachman  Enterprise  Framework  with  the  addition  of 

contextual  named  cells. 

With  the  framework  in  place  the  source  information  can  be  analysed  to  derive  and  classify  entities  about 
which  the  experiment  deal’s  with,  for  example  Permanent  Joint  Head  Quarters  (PJHQ),  Component 
Command  (CC),  Air  Tasking  Order  (ATO),  and  so  forth. 

4.3  The  Conceptual  Battlespace  versus  The  Battlespace 

These  derived  entities  are  abstracted  within  each  cell  of  the  framework  to  identify  common  themes  or 
relationships.  For  example  PJHQ  and  Component  Command  could  be  abstracted  into  a  ‘Command  Node’. 
These  conceptual  entities  are  in  the  conceptual  battlespace  layer,  and  start  to  enable  different  sources  of 
information  to  contribute  a  common  understanding  to  a  similar  concept. 

For  example,  if  two  experiments  are  dealing  with  the  planning  processes  in  PJHQ  and  a  Maritime 
Component  Command  (MCC)  respectively,  the  findings  can  now  be  related  through  a  common  abstraction 
called  ‘Command  Node’.  This  enables  the  experimental  findings  relating  to  planning  in  PJHQ  and 
Maritime  CC  from  both  experiments  to  be  applied  to  the  conceptual  ‘Command  Node’.  If  appropriate 
subsequent  experiments  dealing  with  planning  for  example  in  Joint  Force  Head  Quarters  (JFHQ),  to 
identify  and  reuse  these  findings  through  the  use  of  the  use  of  the  concept  ‘Command  Node’. 

This  is  obviously  a  simple  example  but  with  multiple  abstractions  through  multiple  cells  of  the  framework, 
connecting  a  range  of  experimental  findings  and  by  further  grouping  the  abstractions,  a  more  detailed 
understanding  can  be  reached.  Additionally  these  connections  through  the  layers  can  be  used  to  start  to 
quantify  the  synergy  between  different  experiments. 

4.4  Architectural  Patterns  and  Aesthetics 

A  ‘pattern’  has  been  identified  as  “an  idea  that  has  been  useful  in  one  practical  context  and  will  probably 
be  useful  in  other.”  [5]  .  By  identifying  common  concepts  across  experiments  it  can  be  assumed  that  they 
will  be  useful  to  a  future  experiment  that’s  dealing  with  the  real  world  of  operational,  warfighter  and 
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equipment  capability.  In  the  context  of  the  conceptual  battlespace  architecture  the  attributes,  operations 
and  interactions  between  conceptual  entities  are  used  to  represent  a  pattern.  Figure  4  shows  a  simple 
representation  of  a  pattern  for  the  abstract  concept  ‘command  node’. 


Figure  4  -  A  simple  pattern  of  the  abstract  concept  ‘Command  Node’  showing  the  attributions 

and  operations. 

A  pattern  can  be  created  about  any  aspect  of  the  battlespace,  and  is  not  limited  by  size  or  complexity. 
Conceptual  entities  can  feature  in  multiple  patterns  which  means  there  is  considerable  cohesion  between 
patterns.  Through  these  relationships  new  patterns  can  build  on  or  redefine  existing  patterns. 
Unfortunately  these  dependencies  can  cause  considerable  re-work  as  a  change  to  one  pattern  can  affect 
many.  In  practice  it  has  been  found  that  patterns  should  exhibit  a  degree  of  encapsulation  to  ensure  that 
the  interactions  between  patterns  are  manageable. 

A  pattern  has  associated  with  it  textual  observations  that  capture  features  or  guiding  principles  that  are 
taken  from  the  source  material  and  represent  the  ‘softer’  aspects  of  the  experimental  findings.  They  are 
akin  to  Enterprise  Aesthetics  [7].  For  example,  were  the  planning  processes  identified  by  the  experiment 
dealing  with  PJHQ  well  formulated  or  did  they  have  weaknesses. 


4.5  An  Architectural  Frameworks  supported  by  a  Meta-Model 

The  development  of  the  architecture  is  an  iterative  activity  that  continually  incorporates  new  sources  of 
information  and  develops  patterns.  Current  source  information  includes; 

•  Experiment  Findings; 

•  Experiment  Architectures; 

•  Experiment  Objectives; 

•  Concepts  and  Doctrine; 

•  MOD  Architecture  Repository  (MODAR). 
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To  ensure  that  the  architecture  is  developed  in  a  coherent  manner  a  rigorous  mechanism  of  traceability 
between  all  the  entities  needed  to  be  enforced,  which  both  supports  configuration  control  and  allows  an 
incremental  growth  of  the  architecture  both  in  terms  of  sophistication  and  value.  This  is  underpinned  by 
the  use  of  a  meta-model  which  provides  the  basis  for  the  construction  of  consistent,  coherent  and 
queryable  models. 

An  enterprise  meta-model  that  has  been  developed  by  the  IA  was  used  in  the  conceptual  battlespace 
architecture8.  This  meta-model  has  been  implemented  in  the  Integrated  Service  Support  Environment 
(ISSE)9  modelling  application  and  was  chosen  as  the  modelling  application  to  develop  the  conceptual 
battlespace  architecture. 


5.0  EXPLOITATION  OF  THE  ARCHITECTURE 

The  basic  premise  in  exploitation  of  the  model  is  through  the  query  of  the  relationships  within  and 
between  layers  of  the  conceptual  architecture  and  the  reliance  of  the  adherence  of  the  model  to  the  meta¬ 
model.  The  following  sections  provide  a  brief  overview  of  how  the  model  has  been  exploited  to  deliver 
the  previously  discussed  key  features.  It  should  be  noted,  that  due  to  release  restrictions,  this  paper 
focuses  on  the  exploitation  concept  rather  than  on  specific  outputs. 

5.1  Situating  Experimentation  in  the  Battlespace 

Through  the  classification  of  entities  within  each  layer  of  the  model  and  the  way  they  relate  to  other  layers 
provides  a  means  to  situate  the  experimentation  in  the  battlespace  in  terms  of  impact,  coverage  and 
knowledge,  see  Figure  5. 


g 

At  the  commencement  of  this  piece  of  work  the  MODAF  meta-model  (www.modaf.com)  had  not  been  finalised.  It  is  planned 
that  the  IA  Enterprise  Meta-Model  will  merge  with  the  now  published  MODAF  meta-model. 

g 

ISSE  is  developed  by  the  UK  Ministry  of  Defence's  Integration  Authority.  ISSE  itself  has  been  developed  as  a  SysML-based 
enterprise  architecture  modelling  tool  and  as  a  repository  of  interconnected  models  of  the  elements  of  MoD's  enterprise 
architecture. 
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Views 


Knowledge  -  The  relationship  of 
source  information  to  the  abstract 
entities  provides  a  indication  of  the 
experiment’s  contribution  to  the 
conceptual  layer  and  hence  the 
captured  knowledge  in  the 
architecture. 


Coverage  -  The  distribution  of  the 
derived  entities  provide  an 
understanding  of  the  coverage  of 
the  experiment  in  the  battlespace. 


Impact  The  classification  of  the 
experimental  findings  provides  an 
indication  of  where  it  impacts  on  the 
battlespace. 


Figure  5  -  The  different  ways  experimentation  can  be  situated  in  Battlespace  in  terms  of  Impact, 

coverage  and  Knowledge. 

The  same  idea  of  understanding  the  relationships  from  one  experiment  through  the  layers  of  the  model  can 
be  expanded  to  gain  an  understanding  of  how  an  experiment  relates  to  other  experiments  in  terms  of 
impact,  coverage  and  knowledge.  This  supports  the  identification  of  communality  and  trends  to  enable  the 
generation  of  new  patterns  and  to  reinforce  existing  patterns.  If  an  experiment  can  be  referenced  to 
another  experiment,  by  the  inclusion  of  alternate  frameworks  as  source  information,  it  follows  that  any 
experiment  can  be  referenced  against  this  alternate  framework  e.g.  Defence  Capability  Framework  (DCF), 
NATO  Architecture  Framework  (NAF).  This  provides  a  means  to  translate  concepts  from  one 
organisation  to  another  that  are  using  different  frameworks.  This  idea  is  illustrated  in  Figure  6. 


e.g.  The  UK  Defence  Capability 
Framework 


Figure  6  -  By  the  mapping  of  an  alternate  framework  into  the  Zachman  Framework  an 
experiment  can  be  translated  onto  this  alternate  framework. 
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5.2  Semantic  queries 

Through  the  development  of  the  model  and  the  abstraction  of  commonality  between  entities  within  the 
battlespace  to  the  conceptual  layer  the  basis  of  taxonomy  is  formed.  Furthermore,  within  each  cell  of  the 
framework  the  conceptual  entities  are  further  abstracted  to  build  on  this  classification.  Additionally,  the 
classification  of  the  entities  within  the  Zachman  Framework  and  the  meta-model  provides  additional 
meaning  to  the  entities.  With  this  understanding  of  the  relationship  between  entities  which  in  effect 
represent  context,  these  relationships  can  be  used  to  support  searching  by  meaning:  that  is  semantic 
queries.  Primarily,  this  feature  was  used  simply  to  provide  the  ability  to  overcome  variation  in 
terminology  and  interpretation  of  meaning  between  experiments. 

For  example,  two  experiments  one  dealing  with  command  processes  and  the  other  dealing  with  logistics 
could  both  deal  with  PJHQ.  The  first  experiment  considered  PJHQ  an  operational  role  that  undertakes 
command  processes,  the  second  could  consider  it  a  resource  that  needs  to  be  sustained.  In  this  case  PJHQ 
would  be  classified  as  an  Operational  Node  and  as  an  Operational  Resource  so  the  findings  from  each  of 
experiment  could  be  associated  to  two  different  representations  of  PJHQ.  Additionally  a  third  experiment 
could  have  been  dealing  with  HQs  and  after  investigation  it  was  found  that  this  was  a  short  hand  used  by 
the  experiment  for  PJHQ.  By  building  relationships  to  a  common  ‘Command  Node’  then  subsequent 
searches  from  a  ‘Command  Node’  would  reveal  HQ  and  PJHQ  are  the  same,  in  this  case. 

5.3  Generation  of  Battlespace  Templates 

In  the  context  of  this  work,  the  relationships  that  have  been  captured  within  a  pattern  are  used  to  generate 
architectural  templates.  The  basic  elements  that  would  appear  in  a  template  are  again  classified  into  the 
framework  and  specialised  to  the  appropriate  conceptual  entity(s).  The  relationships  and  attributes  that  are 
inherited  by  the  template  entities  can  be  queried  to  generate  architectural  products  e.g.  MODAF  views  [8]. 
This  is  illustrated  in  Figure  7. 


Command  Node  Pattern 


Conceptual  Layer 
Battlespace  Layer 


1  -  Types’  of  Command  Nodes  are 
created  to  represent  entities  within  the 
Battlespace  which  inherit  the  properties 
of  the  pattern. 


'  Srope?at!on :  Level  of  Operation 

/  level  OfOpe^atlon  :  Level  of  Operation 

lllljbsr 

Specific  Command  Nodes 


2  -  The  inherited  properties  of  each  new 
Command  Node  are  exploited  to 
generate  templates,  which  can  be  use 
as  the  basis  for  the  development  of 
Architectural  Products 


Plan;Exception;OrdenRequest;Awareness;R 


Assessment;Request;Activity 

Command  Node  3  |pian  E.cei _ 


Example  Architectural  Templates 


Figure  7  -  Illustration  of  how  a  ‘Command  Node’  pattern  can  be  used  to  generate  architectural 
products  that  contain  multiple  types  of  ‘Command  Nodes.’ 


6-10 


RTO-MP-MSG-045 


NATO 

OTAN 


The  Use  of  a  Conceptual  Battlespace  Architecture 
to  Manage  and  Exploit  Concepts  and  Doctrine  Experimentation 


5.4  Deriving  knowledge  to  support  both  new  experimentation  and  doctrine 

The  derivation  of  knowledge  is  from  the  result  of  analysis  by  a  user.  However  the  approach  supports  this 
analysis  by  providing  the  ability  to; 

•  Collate  Tike’  things  to  support  the  identification  trends  and  commonality; 

•  Manipulate  findings  into  different  contexts; 

•  Compare  findings  from  multiple  experiments; 

•  Relate  experimental  findings  against  Doctrine  and  Concepts; 

•  Relate  experimental  findings  against  an  architectural  representation  of  the  battlespace; 

•  Query  experimental  findings  by  meanings; 

•  Act  as  a  single  repository  of  all  experimental  findings  from  an  organisation. 

6.0  LESSONS  LEARNT 

This  work  has  been  ongoing  since  April  2005  along  with  a  number  of  activities  to  explore  methods  of 
combining  the  outputs  from  multiple  experiments.  At  present  the  features  set  out  above  have  successfully 
been  demonstrated  with  the  development  of  an  exploitable  architecture  based  on  outputs  from  a  number  of 
experiments10,  doctrine  and  external  architecture  material.  It  has  been  found  that  in  order  to  construct  a 
conceptual  battlespace  architecture  which  will  enable  the  maximum  benefit  it  must  be  established  at  the 
heart  of  the  experimental  regime: 

•  Context  of  Source  Information  -  The  context  of  experiments  must  be  thoroughly  described  to 
enable  the  source  information  from  the  experiment  to  be  incorporated  into  the  conceptual 
battlespace  architecture  to  be  exploited.  Importantly,  it  must  be  possible  to  incorporate 
experimental  observations  at  the  appropriate  level  of  abstraction  to  enable  it  to  be  re-applied  in  a 
meaningful  manner.  There  is  a  danger  of  source  information  being  so  specific  and  de- 
contextualised  as  to  make  it  irrelevant  outside  of  the  context  of  the  experiment. 

•  Depth  of  Source  Information  -  A  ‘critical  mass’  of  information  needs  to  develop  to  enable  the 
conceptual  battlespace  architecture  to  be  of  value.  This  is  achieved  by  the  capture  of  source 
information  to  a  suitable  depth  that  is  beyond  simply  capturing  the  experimental  conclusions  and 
should  include  the  reasoning  and  justification  behind  these  conclusions.  Particularly  the 
descriptions  of  the  architecture  used  in  an  experiment  provide  context  and  reference  to  the  real 
battlespace  architecture  it  is  addressing. 

•  External  Reference  Material  -  The  source  information  derived  from  experiments  needs  to  be 
complemented  in  the  conceptual  battlespace  architecture  by  external  reference  material  which 
describes  both  doctrine  and  capability  architectures.  Thus  experimental  findings  to  be  placed 
against  common  frames  of  reference  and  be  represented  in  commonly  understood  military 
contexts. 

•  Generalisation  and  Classification  of  the  Battlespace  -  It  is  important  to  the  usefulness  of  future 
exploitation  that  the  conceptual  battlespace  architecture  is  created  through  a  single  method  of 
information  interpretation  and  analysis.  Consequently  the  process  of  classifying  and  generalising 
needs  to  be  rigorously  controlled  through  peer  review  and  a  clear  understanding  of  the 
architecture  framework. 


10  Approximately  the  outputs  and  lessons  learnt  of  10  NITEworks  experiments  have  been  incorporated.  A  typical  NITEworks 
experiment  has  duration  of  about  6  months  with  a  team  size  of  20  plus  people. 
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The  UK  MOD  IA  has  established  an  MOD  centre  of  excellence  for  architectural  modelling  which  is 
populating  a  repository  of  interconnected  architectural  models.  The  repository  contains  architectural 
descriptions  of  doctrine  and  equipment  capabilities.  It  forms  a  defacto  MOD  Architectural  Repository 
(MODAR).  A  corollary  of  the  observations  above  is  that  there  should  be  a  strong  relationship  between  the 
information  held  in  the  conceptual  battlespace  architecture  created  by  NITEworks  and  MODAR  (in 
practice  the  IA’s  repository).  The  IA’s  repository  contains  the  contextual  information  necessary  for 
NITEworks  experiments;  conversely  NITEworks  experiments  make  observations  about  the  architectures 
described  in  the  repository.  At  the  time  of  publication  of  this  paper,  negotiations  to  create  such  a 
relationship  are  taking  place. 


7.0  CONCLUSIONS 

This  paper  has  discussed  an  approach  that  has  been  used  to  elicit  additional  value  from  a  range  of 
experimentation,  doctrine,  concepts  and  architectures.  The  paper  has  identified  a  set  of  features  that  such 
an  approach  should  exhibit.  These  features  have  been  derived  from  the  experience  gained  during  work 
undertaken  on  behalf  of  the  UK’s  NITEworks  programme.  This  work  has  resulted  in  the  concept  of 
conceptual  battlespace  architecture  and  has  highlighted  the  need  for  an  architectural  framework  and  meta¬ 
model  to  ensure  the  consistent  and  coherent  development  of  exploitable  architectural  models  based  on 
observations  derived  from  experiments.  The  paper  has  described  the  realisation  of  a  conceptual 
battlespace  architecture  using  the  ISSE  toolset,  highlighted  how  the  conceptual  battlespace  architecture 
can  be  exploited  to  achieve  the  proposed  benefits  and,  on  the  basis  of  lessons  learnt  in  realising  the 
conceptual  battlespace  architecture,  identified  a  number  of  necessary  criteria  for  ensuring  the  maximum 
exploitability  of  experimental  observations  beyond  the  context  of  the  original  experiment.  Meeting  these 
criteria  will  ensure  that  experiments  produce  information  that  is  re-useable  beyond  the  motivation  for  the 
issues  which  originally  led  to  the  experiment. 
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Background 


■  UK  Integration  Authority  (IA) 

■  Part  of  the  UK  Defence  Procurement  Agency  (DPA) 

■  Facilitate  coherent  acquisition  of  military  capability 

■  Developed  MODAF  to  enable  this 

■  NITEworks 

■  Innovative  partnership  between  the  UK  MOD  and 
Industry 

■  Deliver  experimentation  to 

■  Understand  NEC  based  on  the  UK  MOD’S  priority  issues 

■  Demonstrate  the  value  of  experimentation  to  NEC 

■  Identify  where  innovative  technology  could  be  exploited 


Motivation 


“..unless  systems  engineering  capability  and  vital  long-term 
knowledge  is  maintained,  it  is  little  use  investing  in  cutting- 
edge  science.  New  technologies  will  have  less  benefit 
without  knowledge  of  how  they  might  be  exploited  and 

inserted  into  existing  equipment.  ” 

UK  Defence  Industry  Strategy 


The  Problem 


■  Experimentation  is  a  means  to  enable  effective  definition, 
development  and  delivery  of  NEC  &  EBO 

■  NITEworks  uses  experimentation  to  support 

■  Operational  Development 

■  Warfighter  Development 

■  Capability  Development 

I - 1 


How  can  the  findings  from  a  range  of 
experiments  be  combined  to  add  value? 


Features  of  a  solution 


Improved  capability  to  Derived  knowledge  Enhanced  architectural 
deliver  experimentation  from  experimentation  description 


Generate  Derived 
knowledge 
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Architectural  Patterns 


“an  idea  that  has  been  useful  in  one  practical  context 
and  will  probably  be  useful  in  other.”  -  M  Fowler 


■  useful  to  a  future 
experiment 

■  created  about  any  aspect 
of  the  battlespace 


commandNod^  > 
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hosts 


■  new  patterns  can  build  on 
or  redefine  existing 
patterns 

■  capture  ‘softer’  aspects  of 
the  experimental  findings 
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Semantic  Queries 
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1  -  ‘Types’  of  Command  Nodes  are 
created  to  represent  entities  within  the 
Battlespace  which  inherit  the  properties  of 
the  pattern 
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Specific  Types  of  Command  Nodes 
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,  „  ,  Command  Node 

«Military  Role» 

Command  Node  3 

Superior 
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«Military  Role» 

Command  Node  2 

/  mobility :  Mobility 

/  levelOfOperation  :  Level  of  Operation 

/  mobility :  Mobility 

/  levelOfOperation  :  Level  of  Operation 

/  mobility :  Mobility 

/  levelOfOperation  :  Level  of  Operation 

/  respond(exception, order) 

/  direct(request.order) 

/  co-ordinate(request,activityPlan, assessment) 

/  collaborate(awareness, assessment) 

/  plan(activityPlan,assessment,resourcePlan) 

/  understandSituation(assessment) 

/  respond(exception, order) 

/  direct(request, order) 

/  co-ordinate(request,activityPlan  .assessment) 

/  collaborate(awareness,  assessment) 

/  plan(activityPlan, assessment, resourcePlan) 

/  understandSituation(assessment) 

/  respondfexception, order) 

/  directfrequest, order) 

/  co-ordinate(request,activityPlan, assessment) 

/  collaborate(awareness,  assessment) 

/  planfactivityPlan.  assessment,  resourcePlan) 

/  understandSituation(assessment) 

Command 
Node  2 


Example  Architectural  Templates 


2  -  The  inherited  properties  of  each  new 
Command  Node  are  exploited  to  generate 
templates,  which  can  be  use  as  the  basis 
for  the  development  of  Architectural 
Products 


Command  Node  1 

Command  Node  2 

Command  Node  3 

Command  Node  1 

Activity 

Plan;Request;Assessment;Order;Awareness 
;Resource  Plan; Exception 

Activity 

Plan;Awareness;Request;Assessment;Order 
;Exception;Resource  Plan 

Command  Node  2 

Assessment;Activity 

Plan;Exception;Order;Request;Awareness;R 
esource  Plan 

Request;  Activity 

Plan;Assessment;Exception;Order;Awarene 
ss; Resource  Plan 

Command  Node  3 

Assessment;  Request;  Activity 

Plan;Order;Awareness;Resource 

Plan;Exception 

Assessment;Request;Order;Awareness;Acti 
vity  Plan;Exception;Resource  Plan 

Derived  Knowledge 

■  Derivation  of  knowledge  is  by  an  Analyst 

■  Approach  supports  the  Analyst  by 

■  Collating  ‘like’  things  to  support  the  identification  trends  and 
commonality 

■  Manipulating  findings  into  different  contexts 

■  Comparing  findings  from  multiple  experiments 

■  Relating  experimental  findings  against  Doctrine  and  Concepts 

■  Relating  experimental  findings  against  an  architectural 
representation  of  the  battlespace 

■  Querying  experimental  findings  by  meanings 

■  Acting  as  a  single  repository  of  all  experimental  findings  from  an 
organisation 
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Lessons  Learnt 


■  Context  of  Source  Information 

■  Depth  of  Source  Information 

\ 

■  External  Reference  Material 

■  Generalisation  and  Classification  of  the  Battlespace 


Conclusions 


■  Creating  generalBiowledge  from  specific  experiments  is 
challenging 

■  CBA  is  an  approach  to  elicit  additional  value  from  a  range 
of  experimentation,  doctrine,  concepts  and  architectures 

■  Used  as  part  of  the  UK’s  NITEworks  programme  and  has 
demonstrated  its  potential  value 

■  Through  practical  experience  we  have  identified  a  number 
of  prerequisites  to  enhance  the  likelihood  of  success 
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Questions? 


